t Application Builder: Life in the Fast and Easy Lane
t Prograph System Classes and Application Builder
Editors
t Prograph Development Styles
t Prograph Structured Development
t Prograph Evolutionary Development
t Check Your Progress
*53*The objective of this chapter’s tutorial is to provide the Prograph-specific conceptual foundation that can help you to understand and use Application Builder. Understanding Application Builder means understanding both the System Class Hierarchy and its associated specialized System class editors.
Application Builder’s editors provide a powerful control center for creating and maintaining instances of Prograph System classes, thereby simplifying the development of applications with full Macintosh interfaces. As noted in chapter 4, “Conceptual Foundations,” Application Builder is a full-featured application *1101*toolkit *77*— a fully integrated collection of editors and*867* OOP*775* classes that dramatically increases your productivity in providing a user interface to your application.
t Why the Toolkit Approach?
*888*The overriding design goal for the Prograph development team has always been to provide programmers with a complete development system that allows their applications to evolve in the natural and interactive way each programmer works. They have succeeded in doing this by designing a fluid system that integrates development of the “look and feel” of an application along with its underlying computational behavior. Prograph’s Application Builder—its user-interface*1135* toolkit—provides seamless integration between the processes for developing the user interface and the classes and methods that implement the fundamental behavior of the application itself. This is a revolutionary approach to program development, especially on the Macintosh.
The chief design alternative to an interface toolkit—the User-interface Management System*1132* (UIMS)*1138* approach—actually separates the user interface design and code implementation from code specific to the application’s specialized functions. That is, a UIMS compartmentalizes the interface as distinct from the application itself. This approach is shortsighted with respect to how programmers work in the real world.
On the Macintosh, this separate-but-equal approach to interface or application development is a part of the history of Macintosh development in general. Mac development tools*551* have been built largely on two parallel fronts. Third-party developers have concentrated on providing the best language and compiler products, while Apple has continually improved specialized editors for creating various resources such as dialog boxes and window templates. To a large extent, this separation of interface and application among development tools still applies, as in Apple’s MacApp*549*/MPW*738*/ViewEdit combination.
Discrete tools—a UIMS for development of a distinct interface, and a separate programming language for developing the application—are far better than a completely “raw” development system that requires that the entire application and its interface be written from scratch, with only the help of a program editor. But UIMS approaches are considerably less attractive in projects that have an evolutionary design and implementation cycle. In such projects, it is not so easy to separate the interface from the application. One is intimately entwined with the other.
That is why the Prograph International designers have insisted that an application toolkit, Application Builder, be an integral part of Prograph. Your application and its interface evolve together, naturally and in concert, not as separate threads. In the race for powerful toolkit functionality, Application Builder stands out for its concurrent execution of the Prograph editors and your application. As you will see in this tutorial, Prograph provides capabilities for creating and modifying both existing instances of classes and the classes themselves while your application execution is suspended and then resumed.
You had a taste of Application Builder’s power in the Grand Tour, but much was left unexplained. In this tutorial, the connection between Application Builder’s specialized editors and the Prograph System classes is more fully explained. In showcasing features of Application Builder’s editors, special emphasis is put on an evolving case-study example that demonstrates the fluid nature of the Prograph application-development cycle.
As you extend your experience and knowledge of Application Builder, your knowledge of and skills with Prograph classes and methods come into play. If you have not been moving sequentially through the tutorials, you might consider backtracking and doing the Language Basics tutorials in chapters 6 and 7 before starting here. Those earlier tutorials provide a sound foundation for putting Application Builder to work for you.
t Understanding Application Builder by Programming Without It*54*
*44*In chapter 3, “The Grand Tour: Application Builder,” you saw how Application Builder’s specialized editors provided a comfortable and productive layer of organization over the Prograph System classes. You used the Application, Menu, and Window editors to create a simple database application. At that point in your evolving exposure to Prograph, it was left unsaid how these editors specifically relate to the System classes.
Now that you have a richer understanding of Prograph’s class structure, inheritance, and method behaviors, the connection between Application Builder and the System classes can be made explicit.
*1102*To understand Application Builder, first understand Prograph as a base language. If you wanted to approach Prograph as a*542* low-level*862* environment—that is, if you wanted to think about Prograph with an assembly-language programmer’s mind set—you could write sophisticated applications in Prograph, with full Macintosh interfaces, without using Application Builder. You could even write such applications without using Prograph’s object-oriented class features at all.
Such a low-level Prograph programmer might write his or her entire application as one huge universal method or as a series of interconnected universal methods. These universal methods would use a wide range of Prograph’s built-in primitives. In addition, such a developer would have to make extensive use of the many hundreds of Macintosh Toolbox*560* methods, accessing and manipulating the various Macintosh data structures directly.
Before you delve into Application Builder, have a taste of what life without Application Builder would be like.
u Launch Prograph from the desktop. Open the ˙Info… dialog and take a look at the*546* Mac Methods*462*. Scrolling through the list of these Toolbox procedures, you get an idea of the extensive machine-level access Prograph supplies to the Macintosh.
u Create a universal method, A Do-It-Yourself Window, and edit its first case—including its local method close click?, to look like the following picture. (The second input to NewWindow is the Macintosh Rect data {50 50 300 300} and the left input to FlushEvents is a Mac Constant operation, everyEvent. Also note that the close click? local method has been annotated with a Repeat multiplex control.)
 
Make sure you connect synchros from close click? to DisposeWindow to FlushEvents. This makes sure the window is not disposed of before its close box is clicked, and that any clicks during this window’s life are removed from the Macintosh event queue.
Since this window is only looking for mouse clicks in the close box, events can accumulate in the event queue. If this method did not have a FlushEvents operation as its last action, clicks made in the A Do-It-Yourself Window would be reacted to by whichever became the active window when the Prograph editor reopened its windows.
Without FlushEvents, you could see new, nameless method icons in the Universal Methods window if it became the active Prograph editor window, or you could get new, nameless operations in the A Do-It-Yourself Window case window if it became the active Prograph editor window. This is just one aspect in the complexity of monitoring and reacting to Macintosh events directly without Application Builder.
u Execute A Do-It-Yourself Window. Try to zoom the resulting window. Try to drag it and otherwise react to it in any way other than by clicking on its close box. When you have convinced yourself that this window is rather useless, click its close box to close and dispose of this window by finishing execution of the A Do-It-Yourself Window method.
The NewWindow Mac Method is a Toolbox procedure that takes eight input parameters. The third parameter is a string data type, NewWin in this example, that appears in the title bar of the window resulting from execution of this method. For the full meaning and function of the other parameters you can turn to Inside Macintosh *489* if you are really interested. You would need to check into these and many other low-level details about the functioning of the Macintosh if you were going to be a do-it-all-yourself Prographer.
To further make this window useful, you would need to construct the traditional Macintosh main-event loop, which looks for and reacts to user interaction with this window. If you have ever programmed the Macintosh with first-generation procedural languages, you know what a headache this can be.
In the current method, the close click? local method is a grossly simplistic substitute for a complete main-event loop. This repeat multiplex is looking only for an “inGoAway” mouse click (output from the FindWindow operation). If you wanted to add normal Macintosh window behavior to this window, you would have to trap all kinds of Macintosh events and respond explicitly to them with separate cases in an event-loop*323* method. As you can imagine, programming at this low-level of the Macintosh can be extremely tedious and error prone—even when using Prograph’s visual capabilities.
